Would it make sense to use a containerised environment for this?

#14

If it slowed this PR down too much then it might make sense to make containerisation a subsequent PR.

Would it make sense to use a containerised environment for this?

I've been wanting to learn about using singularity containers so I'll be keen to try that

Updates:
Leaving containerised payu to a separate PR due to time constraints

Add a job to check if there's been any new commits to the master branch payu-org/payu repository, since the last successful payu dev deployment workflow run. This check will run periodically.
A new environment will get deployed if there's new commits, or if the environment file has changed or on manual dispatch (so can get new environment ASAP if needed).

New environment will get deployed to /g/data/vk83/prerelease/apps/payu/dev-$VERSION. Once installed the /g/data/vk83/prerelease/apps/payu/dev symlink will be created - these will be used for when the payu/dev module is loaded. The environment that the symlink previously pointed to be will remain, as the environment could be actively used at time of deployment. Older payu/dev environments are removed.

The versions of dev environment dev-YYYYMMDDTHHMMSSZ-$SHORT_PAYU_GIT_HASH, so they are unique. Having time included is a bit unwieldy, but I was thinking of the case where the dev environment file could be updated twice in one day - which probably wouldn't happen often..

Updated modulefiles deployment to generate modulefiles for release and prerelease and sync to respective locations (the common module file and env.sh uses different paths).

TODO:

• Frequency/time of the cron job? Every hour/every day?